Cuando OpenAI describió RLHF como la técnica detrás de InstructGPT en 2022, el panorama del alineamiento de modelos de lenguaje pareció resuelto conceptualmente. RLHF era caro pero funcionaba, y durante un tiempo fue el método por defecto para cualquier fine-tuning serio con preferencias humanas. Tres años después, ese monopolio se ha desvanecido: DPO demostró que se podía lograr un resultado similar con mucho menos esfuerzo, y desde entonces han aparecido variantes (KTO, ORPO, SimPO) que prometen simplificar todavía más el proceso.
Este post es una revisión práctica del estado actual: cuándo tiene sentido cada método, qué coste tiene, qué resultados producen en contextos reales, y qué criterios usar para elegir. No es una introducción teórica sino una lectura aplicada, pensada para quien está construyendo un pipeline de alineamiento y tiene que tomar decisiones.
El problema que todos resuelven
El objetivo común es el mismo: partir de un modelo pre-entrenado y fine-tuneado en instrucciones, y ajustarlo para que responda conforme a preferencias. Las preferencias pueden ser «responde de forma útil», «no produzcas contenido dañino», «adopta este estilo», «prioriza la brevedad», lo que corresponda al caso.
Todos los métodos parten del mismo insumo: pares de respuestas etiquetadas como «mejor» y «peor» según algún criterio (preferencia humana, comparación con un oráculo, o evaluación programática). Lo que cambia entre métodos es cómo se usa ese dataset para actualizar los pesos del modelo.
RLHF: el clásico
RLHF entrena primero un modelo de recompensa que predice cuánto le gustará a un humano una respuesta dada. Después usa aprendizaje por refuerzo (típicamente PPO) para optimizar el modelo de lenguaje maximizando esa recompensa, con restricciones de KL divergence para evitar que se aleje demasiado del modelo base.
Ventajas: es el método mejor estudiado, produce resultados de calidad alta, y el modelo de recompensa permite evaluar respuestas nuevas fuera del entrenamiento.
Inconvenientes: es caro computacionalmente (tres modelos activos simultáneamente durante el entrenamiento: política, referencia, recompensa), es inestable (el ajuste de hiperparámetros es notoriamente difícil), y requiere un dataset de preferencias grande y de buena calidad para funcionar bien.
Cuándo usarlo: cuando tienes recursos (equipo de investigación en ML, presupuesto computacional, tiempo para iterar), cuando quieres poder reutilizar el modelo de recompensa para evaluación offline, o cuando la complejidad del criterio de alineamiento es alta y necesitas un modelo de recompensa explícito que lo represente.
DPO: la simplificación
DPO (Direct Preference Optimization) llegó en 2023 con una idea simple: puedes reformular el problema de RLHF de tal manera que el modelo de recompensa implícito sea el propio modelo de lenguaje, y entonces puedes entrenar directamente contra pares de preferencias sin PPO, sin modelo de recompensa separado, sin la complejidad.
En la práctica, DPO funciona sorprendentemente bien. La calidad del modelo resultante es muy cercana a la de RLHF en la mayoría de benchmarks, y el coste de entrenamiento es una fracción. Esto ha hecho que DPO sea hoy el método más común en la comunidad abierta: prácticamente todos los fine-tunes públicos de Llama, Mistral o Gemma lo usan.
Ventajas: mucho más simple de implementar, mucho más rápido de entrenar, menos sensible a hiperparámetros, funciona bien con datasets más pequeños.
Inconvenientes: no produce un modelo de recompensa reutilizable, es ligeramente peor que RLHF bien ajustado en tareas muy complejas, y tiende a producir respuestas más largas que el modelo base (un sesgo bien documentado del método).
Cuándo usarlo: para la mayoría de casos de alineamiento estándar, especialmente si estás en un entorno open source, con recursos moderados y dataset de preferencias de tamaño modesto.
Las variantes recientes
Durante el último año han aparecido varias alternativas a DPO que intentan mejorar uno u otro aspecto.
KTO (Kahneman-Tversky Optimization) toma prestado del razonamiento de economía conductual: en vez de pares de preferencias, usa respuestas etiquetadas individualmente como deseables o no deseables. La ventaja es que los datasets son más fáciles de construir (no necesitas comparaciones, solo etiquetas), y la calidad del resultado es comparable a DPO en muchos casos. Si tu fuente de datos es naturalmente binaria (respuestas buenas vs respuestas malas sin par), KTO encaja mejor.
ORPO (Odds Ratio Preference Optimization) fusiona el fine-tuning supervisado inicial y el alineamiento en un solo paso, eliminando la fase de SFT previa. Esto simplifica el pipeline y, en algunos papers, da resultados iguales o mejores que SFT+DPO. Es interesante para quien quiere pipelines más cortos.
SimPO (Simple Preference Optimization) propone una reformulación de DPO que usa la longitud de secuencia normalizada como referencia, eliminando la necesidad del modelo de referencia. Esto reduce el coste de memoria en entrenamiento. Los resultados son prometedores pero la adopción en la comunidad es aún modesta.
Qué pasa en la práctica
En equipos con los que he trabajado o cuya publicación he seguido, el patrón que se repite es este: para alineamiento estándar de un modelo de tamaño mediano (7B a 70B) con un dataset de preferencias humanas razonable, DPO es el default y no hay razón fuerte para cambiarlo.
KTO se adopta cuando el dataset viene en formato binario (por ejemplo, feedback de usuarios en producción donde hay respuestas aprobadas y rechazadas, pero no pares explícitos). ORPO se prueba cuando se quiere simplificar el pipeline, y funciona particularmente bien cuando se combina con datos de instrucción del mismo estilo que las preferencias. SimPO aparece más en papers que en producción.
RLHF se reserva para casos muy específicos: modelos de frontera donde los últimos puntos porcentuales importan mucho, casos donde se necesita un modelo de recompensa reutilizable para evaluación continua, o cuando el criterio de alineamiento es complejo y multimodal.
Recomendaciones concretas
Si estás empezando un proyecto de alineamiento hoy, mi sugerencia pragmática es:
Empieza con DPO. Es el que más documentación, tutoriales, e implementaciones públicas tiene. Cualquier framework decente (TRL de HuggingFace, Axolotl, Unsloth) te lleva a un pipeline funcional en un día.
Usa un dataset de preferencias de al menos unos cuantos miles de ejemplos. Si tienes menos, KTO puede ser más eficiente porque etiquetado binario es más barato.
Evalúa con un conjunto de validación reservado, con métricas automáticas (ROUGE, BLEU) y con evaluación humana aleatoria. La evaluación puramente automática engaña, especialmente con DPO que tiende a inflar longitud.
Solo pásate a RLHF si, tras probar DPO, tienes evidencia concreta de que te falta calidad para tu caso específico. En la mayoría de proyectos esa evidencia no aparece.
Y prueba una variante reciente (KTO, ORPO) si tu dataset o tu pipeline encajan mejor con sus premisas. No lo hagas por moda, sino porque el método genuinamente encaja con tu escenario.
Mi lectura
Lo que resumo tras tres años de evolución en este espacio es que la barrera para alinear un modelo abierto de forma efectiva se ha desplomado. Lo que en 2022 era proyecto de laboratorio de investigación es hoy fine-tuning en fin de semana con un presupuesto de GPU moderado. Eso no significa que el problema esté resuelto conceptualmente (hay preguntas abiertas importantes sobre alineamiento seguro de modelos de frontera), pero sí que la práctica rutinaria de ajustar un modelo al estilo o la tarea que necesitas es ya accesible para cualquier equipo técnico.
La existencia de variantes nuevas cada pocos meses es señal de que el espacio está vivo. No todos los métodos van a sobrevivir, y probablemente dentro de dos años recordemos varios con cariño como experimentos instructivos más que como técnicas de producción. Pero la tendencia general, hacia menos complejidad y más accesibilidad, es claramente buena para el ecosistema.
